-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add auto upload assets #601
base: main
Are you sure you want to change the base?
Conversation
Now you can manually enter the release tag and action id and it will re-upload the artifact. |
I understand why the action uses the old workflow file. If you select a commit id when releasing, the action will run the workflow in that commit, which may be outdated. Therefore, if you want to upload the artifacts generated by the commit before the merge to the release, you must manually run the workflow and fill in the action id and release tag. |
I completed the test and both the manual and automated runs now upload artifacts as expected. |
I'll take a look at this very soon |
Ok, if you need test this action, tell me and I'll run it on my branch. |
runs-on: ubuntu-latest | ||
|
||
steps: | ||
- name: get latest ci id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the problem I think I see with these steps is there is no check anywhere if the latest CI run is a tag, or if we're even running in a tag
at all.
To me, it just looks like it's going to try automatically uploading binaries every single CI run. I don't know how safe that is.
Here's an example of our Docker publish step, we perform actions based on whether we're in a tag or not: https://github.com/girlbossceo/conduwuit/blob/main/.github/workflows/ci.yml#L511
In this case, I only want to run this if I'm running the workflow from a tag.
I also don't really see anything that replaces existing binaries uploaded. So, if I run a workflow, and re-run it, will it upload two binaries?
Can some safety precautions be added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
every single CI run
This workflow is triggered by publishing, it does not run on every single CI run.
on:
release:
types: [published]
This means that it will only run if you are on the releases page, click publish release, and select a tag.
So, if I run a workflow, and re-run it, will it upload two binaries?
No, if there is already a file with the same name in the release, it will be overwritten. It is done by the clobber of gh cli.
gh release upload $TAG "$file" --clobber --repo="${{github.repository}}"
This document describes the function of clobber.
Can some safety precautions be added?
Of course, I can make the workflow exit with an error when it is triggered by commit. Or I can make it run only when the workflow is triggered by publishing, so that even if the workflow is accidentally triggered, there will be no problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay then I likely misunderstood then. I guess I can just try it out as is and see what happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just enter the action id, and v0.4.7-rc and run it manually, it will upload the action artifact you selected to v0.4.7-rc. You can also run it repeatedly to see if it replaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or you can let me do this in my fork, which would be safer.
When creating a new release, this action will download the latest build artifacts and upload them to Assets.